(19) 



J 



(12) 



(43) Date of publication: 

17.02.1999 Bulletin 1999/07 

(21) Application number: 98112462.1 

(22) Date of filing: 06.07.1998 



Europdisches Patentamt 
European Patent Office 
Office europ6en des brevets (11) EP 0 897 149 A1 

EUROPEAN PATENT APPLICATION 

(51) IntCI. 6 : G06F9/46 



(84) 


Designated Contracting Stales: 


• Carlson, Brent 




AT BE CH CY DE DKES R FR GB GR IE IT U LU 


Rochester, MN 55902 (US) 




MCNLPTSE 


• Dahl, Tore 




Designated Extension States: 


11254 Stockholm (SE) 




ALLTLVMKROSI 


• Graser, Timothy 
Rochester, MN 55901 (SE) 


(30) 


Priority: 14.08.1997 EP 97114039 


• Nilsson, Anders 


(71) 




1481 Hagan (NO) 


Applicant 


• Pasch, Marie 




International Business Machines 


Rochester, MN 55901 (US) 




Corporation 




Armonk, N.Y. 10504 (US) 


(74) Representative: 


(72) 


Inventors: 


Teufel, Fritz, Dlpl.-Phys. 


IBM Deutschland In forma lionssysteme GmbH, 


• 


Carey, James 


Patentwesen und Urheberrecht 




Rochester, MN 55901 (US) 


70548 Stuttgart (DE) 



(54) Framework for business applications providing financial integration 



(57) The present invention relates to a method of 
developing a software system using Object Oriented 
Technology and frameworks for developing a business 
application. 

The present invention solves this problem with a 
framework framework comprising a using non-financial 
component integration base class, a target financial 
component integration base class, and a generic data 
conversion engine. 

The present invention is applicable in the techniclal 
field of application development of software systems, 
e.g. for a business application as Financial or Logistic 
and Distribution, wherein it is the purpose of frame- 
works to provide significant portions of the application 
that are common across multiple implementations of the 
application in a general manner, easy to extend for spe- 
cific implementation. 
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Description 

Held of the Invention 

[0001] The present invention relates to a method of 
developing a software system using Object Oriented 
Technology and frameworks for developing a business 
application. 

[0002] The present application relates to the following 
co-pending applications filed by the same applicant with 
the same filing date: 

"A method of developing a software system using 
Object Oriented Technology" (Applicant's docket 
No. GE 997 034) 

"A method for using decoupled chain of responsibil- 
ity" (Applicant's docket No GE 997 035) 
"Framework for business applications using cached 
aggregate and specification key (Applicant's docket 
No. GE 997 039) 

"Software business objects in a multi-level organi- 
zational structure" (Applicant's docket No. GE 997 
040) 

"Method of error handling in a framework" (Appli- 
cant's docket No. GE 997 041) 
"A method of locating software objects in different 
containers" ((Applicant's docket No. GE 997 042) 

Description of the Prior Art 

[0003] In order to maintain or enlarge their competi- 
tiveness, enterprises of almost every type of business 
all over the world have to rework and bring up to date 
their information technology to meet customer's require- 
ments and thus to be successful in the market But 
keeping an information system based on traditionally 
developed software up to date is at least an expensive 
undertaking, and in many cases it is an unsotvable 
problem. Object Oriented Technology or simply Object 
Technology, often abbreviated "OOT or simply "OT, 
has the technical potential to overcome the problems 
associated with development, maintenance, and exten- 
sion of software applications within a company's infor- 
mation system and to provide interoperability and 
adaptability across multiple applications and hardware 
platforms. 

[0004] Object Oriented Technology descrfces a 
method for the development of operating software as 
well as application software for a computer system. 
Contrary to the traditional, non object oriented ways of 
developing software. Object Oriented Technology com- 
prises and uses preengineered "methods" and "objects" 
for the development of software, comparable to tools 
and parts for the development of an automobile. 
[0005] Similar to the development of an automobile, 
wherein not each required screw is developed individu- 
ally, but standardized screws are used which can be 
individually adapted by shortening to the required 



length, within the development of software, Object Ori- 
ented Technology provides a "class" as a kind of soft- 
ware template from which individual "objects" can be 
instantiated. These classes are usually stored in a soft- 

5 ware Iforary or a so called "class library". A class library 
is simply a collection of several classes stored together 
in a special f fling format called a library. 
[0006] In Object Oriented Technology an "object" is a 
self-contained piece of software consisting of related 

10 data and procedures. Data means information or space 
in a computer program where information can be 
stored, e.g. a name or an inventory part number. Proce- 
dures are parts of a program that cause the computer to 
actually do something, e.g. the parts of a program which 

is perform calculations or the part of a program that stores 
something on a computer disk. In Object Oriented Tech- 
nology, an object's procedures are called "methods". 
[0007] The concept of an object being a serf-contained 
piece of software having data and procedures inside 

20 itself is a new way of developing software. In non object 
oriented software, most of the data for an entire pro- 
gram is often grouped together near the beginning of 
the program, and the procedures then follow this com- 
mon pool of data. This conventional method worked 

25 okay for smaller programs, but as soon as a piece of 
software started to grow and become somewhat com- 
plex, it become increasingly cfifficuft to figure out which 
procedures were using which data. This made it quite 
difficult and expensive to debug or change traditional 

30 software programs. 

[0008] In Object Oriented Technology it is generally 
easier to debug, maintain, and enhance object oriented 
software. The most popular object oriented program- 
ming languages are probably "C++", "JAVA", and 

35 "Smalltalk". The concept that both data and methods 
are contained inside an object is called "encapsulation". 
Part of the concept of encapsulation is that an object 
has a predictable way of communicating with other 
objects, a so called predictable "interlace" or sometimes 

40 also called the method contract 

[9009] Provided that interface will not be changed, the 
code or methods inside the object can be changed with- 
out disrupting other objects' ability to interact with that 
object. For example, a TAX CALCULATION object 

45 would have a predictable interface for use by FAY- 
CHECK objects. Provided that interface wiD not be 
changed, the detailed program code inside the TAX 
CALCULATION object could be changed whenever the 
tax laws changed, and no other objects in the payroll 

so system would have to know anything about such 
changes. 

[001 0] In Object Oriented Technology the term "inher- 
itance" is used to communicate the concept that one 
object can inherit part of its behavior and data from 
55 another object, e g. since an employee is a type of per- 
son, an EMPLOYEE object migjit inherit the character- 
istics of a PERSON object, such as having name, birth 
date, and address data, as well as an EMPLOYEE 
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object might inherit methods for updating and displaying 
these data. 

[001 1] Even if an object inherits some off its character- 
istics from other objects, that object can, and usually 
would, also have its own non-inherited characteristics, s 
e.g. whereas a PERSON object would have an inherita- 
ble method to display a person's address, a PERSON 
object would probably not have a method for displaying 
paycheck history, since not all persons get paychecks. 
Because an EMPLOYEE object could not inherit this 
method from a PERSON object, an EMPLOYEE object 
would have to define its own method for displaying pay- 
check history. 

[0012] Although Object Oriented Technology clearly 
seems to be the most sophisticated way for the develop- 
ment, mainentance, and extension of software applica- 
tions, many companies developing software 
applications are concerned about the cost and risks 
involved with the rework of existing applications and 
with the construction of new applications using Object 
Oriented Technology. For those software application 
developers, a technical foundation for software applica- 
tions has to be built as a tool using Object Oriented 
Technology as the basis, allowing each developer to 
develop highly unique software products. This technical 
foundation is formed by frameworks comprising the 
basic application structure which software application 
developers previously had to develop by themselves. 
[001 3] In Object Oriented Technology the term "frame- 
work'' is used to describe a reusable set or collection of 
classes which work together to provide a commonly 
needed piece of functionality not provided by any of the 
individual classes inside the framework. Thus a frame- 
work defines a specific way in which multiple objects 
can be used together to perform one or more tasks 
which no single object performs. In other words, a 
framework is a reusable, predefined and preengineered 
bundle of several objects which address a recurring pro- 
gramming problem. 

[0014] Frameworks provide a way of capturing a reus- 
able relationship between objects, so that those objects 
do not have to be reassembled in that same relationship 
every time they are needed. Frameworks provide a way 
of grouping multiple objects together to perform some 
function which should not have to be thought through 
each time at the underlying object level. For example, a 
PRINT framework would consist of all the objects nec- 
essary for a programmer to easily print something on 
any printer, and would probably include objects for 
printer selection, spooling to cfisk or error detection as 
"out of paper". Frameworks can be regarded as a group 
of software objects which contain a technical foundation 
for a software application. For example in the business 
field of Financial, Logistic and Distribution or Produc- 
tion. Although a framework represents a skeleton of a 
software application, usually a framework is not an exe- 
cutable software program. 

[001 5] E. GAMMA et al: "Design Patterns: elements of 



reusable object-oriented software", Addison-Wesley, 
1995, ISBN 0-201-63361-2, gives a useful introduction 
to Object Oriented Technology in general and to design 
pattern more specifically, in particular with regard to the 
present invention. 

[001 6] By providing frameworks as the technical foun- 
dation for developing software applications, the follow- 
ing problems have to be addressed: 
[001 7] Applications have to support all hardware plat- 
forms and related software operating systems relevant 
on the market. Applications have to futffll the require- 
ments related to client/server configurations including 
the requirement for graphical user interfaces and win- 
dowing techniques. Also, applications have to offer 
internet compatibility and access on demand. Further- 
more applications have to provide integrated solutions 
with respect to installed software 
[001 8] In particular, the core of most business applica- 
tions is the General Ledger. One of the more difficult 
problems that must be solved by a business application 
is how to enable multiple diverse business application 
components, e.g., payroll/personnel, warehouse man- 
agement, manufacturing, in many cases developed by 
different development organizations, to provide input to 
the General Ledger in a manner which is tailored to 
each component's specific requirements. This task 
must be accomplished while at the same time enabling 
multiple General Ledger components, again developed 
by different development organizations, to interoperate 
with the framework. The framework must also support 
applications that choose not to provide a General 
Ledger component without requiring the remaining 
application components to be modified in any way. 
[0019] In addition, frameworks must be capable of 
supporting flextole representations of a set of non-uni- 
form items. 

[0020] Within the accompanying figures, representa- 
tion standards for classes, objects, relationships etc. are 
used at least partly according to Grady Booch: "Object- 
Oriented Analysis and Design with Applications", sec- 
ond edition, The Benjarrnn/Cumrnings Publishing Com- 
pany, tnd., Redwood City, CA, USA. 

off the Invention 

[0021] It is an object of the present invention to pro- 
vide a technical foundation for the development of soft- 
ware applications using Object Oriented Technology 
which overcomes the above discussed problems. 
[0022] ttisa further object of the present invention to 
enable multiple diverse business application compo- 
nents to provide input to the General Ledger component 
in a manner which is tailored to each component's spe- 
cific requirements. 

Summary of the Invention 

[0023] The present invention solves this object with 
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methods and apparatus as laid down in enclosed inde- 
pendent claims. Particular embodiments of the present 
invention are presented in the respective dependent 
claims. 

[0024] In particular, the present invention provides a s 
framework to be used for developing a software system, 
e.g. for a business application, said framework is a 
financial integration framework characterised in that 
said financial integration framework is composed of 
three major components: Using non-financial compo- w 
nent integration base classes, target financial or Gen- 
eral Ledger component integration base classes, and a 
generic data conversion engine. 
[0025] This invention is easily customizable to any 
specific business application component Furthermore, is 
it enables cross-component data mapping at any level 
of complexity desired by the development organization, 
providing a generic data conversion engine whose 
mechanism is fully functional without development 
organization modification. This engine accepts the 20 
diverse data provided by the other components of the 
framework in the form of domain-specific class 
instances, such as Product, Warehouse, Customer, and 
Stock Type for a warehouse management component 
and converts that data into a form compatible with the 25 
General Ledger framework interface, i.e. Generic Dis- 
sections containing Generic Posting Combinations 
made up of one or more instances of Generic Analysis 
Codes, each of which is associated with a separate 
Generic Analysis Group, ft operates independently of 30 
any General Ledger application component at a basic 
level, while enabling any General Ledger application 
component developed for the framework to easily 
replace the basic level function with its own more 
sophisticated function. 35 

Brief Description of the Drawings 

[0026] 

40 

Figure 1 shews a four layer schema from which soft- 
ware application can be developed using 
the present invention. 

Figure 2 shews the three main sections comprised 45 
by the financial integration framework. 

Figure 3 shows specialized and defairit mappings. 

Figure 4 shows the generic journal building process, so 

Figure 5 shows an example of mapping for one 
Analysis Group for a particular Generic 
Dissection Type. 

55 

Figure 6 shows a more complex example with two 
Generic Dissection types, three Analysis 
Groups, and three Account Control types. 



Figure 7 shows an example of using the maps 
defined in Figure 6. 

Detailed Description 

[0027] Developing software applications using the 
subject of the present invention as a development tool 
can be regarded as built up of four layers as shown in 
Figure 1 . 

[0028] The lowest layer is the base layer 101. The 
base layer 101 provides and manages the interface with 
the server hardware 1 1 1 which is potentially running 
under different operation systems such as OS/2, 
OS/400, AIX, and NT. The server hardware 1 1 1 is con- 
nected with client hardware 112 via a communication 
network 1 13. The client hardware 1 12 may also poten- 
tially running under different operation systems such as 
OS/2, NT, and AIX. The embodiment shown in Figure 1 
shows the development of the saver portion of a cli- 
ent/server application only. 

[0029] The Base layer 101 represents the technical 
foundation for the higher level objects including many 
functions near to an operating system such as finding 
objects, keeping track of their names, controlling access 
to them, resolving conflicts, security administration, and 
installation. The Base layer 101 also includes the so 
called Object Model Classes which provide a consistent 
model for building objects while hiding the complexity of 
the underlying infrastructure form the software applica- 
tion developer. The Base layer 101 can be regarded as 
a kind of lower middleware necessary for the application 
of the Object Technology above it using the interlace 
functionality provided by the Base layer 101 . 
[0030] Above the Base layer 101 there is a layer com- 
prising Common Business Objects 102. This Common 
Business Object layer 102 provides a large number of 
objects which perform functions commonly needed 
within a business application, e.g. date and time, cur- 
rency, address, units of measure, and calendar. These 
Common Business Objects represent the building 
blocks from which software application developers can 
select and create business applications, ag. these 
Common Business Objects can be copied and 
extended to perform new functions as for example the 
date and time object can be extended to handle the Chi- 
nese calendar. 

[0031] The layer 103 above the Common Business 
Objects layer 102 already comprises Core Business 
Processes and can be regarded as the Core Business 
Process layer 103. Although layer 103 usually does not 
provide executable code, within this layer 103 the busi- 
ness software applications developed using the present 
invention begin to take shape. Each Core Business 
Process layer is built for one specific type of application, 
as for example General Ledger or Warehouse Manage- 
ment 

[0032] This Core Business Process layer 103 can be 
regarded as an upper middleware which - although not 
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a complete software application program - already con- 
tains the basic funtions which all of the application pro- 
grams of this type require, ft is the Core Business 
Process layer 103 which creates the application frame- 
works, wherein some of the Common Business Objects 
are linked to a large number of objects specific to the 
type of framework being built, e.g. Warehouse Manage- 
ment. The resulting framework is constructed in a way 
to contain commonly used functions as well as to be 
easy to extend. 

[0033] On top of the above described three layer 
model the application software is located, created by 
the software application developer and representing 
executable code. It is the choice of a software applica- 
tion developer whether to use only the base layer 101, 
the base layer 101 and the Common Business Object 
layer 102, or all three layers 101. 102, and 103 for the 
development of his software application. In every case 
he has to develop a remaining part of the application by 
himself and therefore every resulting software applica- 
tion program will be a completely unique product. 
[0034] It has to be noted that the subject of the present 
invention is represented within the three layer model 
101 , 102, and 103 and is not represented by the execut- 
able code of the software application 121 developed 
using the present invention. 

[0035] As shown in Figure 2, the financial integration 
framework comprises of three main sections 201, 202, 
and 203. The first section 201 is a set of base classes 
which are used by the particular source of financial 
transactions. The second section 202 is a generic data 
conversion engine which uses the specializations in the 
first section 201 as their abstract base classes to map 
from the particular source's particular items of interest 
to associated items in the interface of the General 
Ledger. The third section 203 consists of the interface to 
the General Ledger (GL) which allows information to be 
genetically passed to the General Ledger and hide the 
particular inrplementation or if it is even preset. 
[0036] A business application component that wishes 
to use the financial integration framework must first 
define a set of concrete classes which are subclassed 
from base classes provided by the framework. The func- 
tion of these concrete classes is primarily derived from 
the framework base classes. The domain-specific con- 
crete classes provide additional isolation between the 
business application component and the framework and 
allow the component developer to define a domain-spe- 
cific interface that is meaningful to the remainder of the 
component. This greatly improves ease of use of the 
framework during application development 
[0037] In an embodiment of the invention, the follow- 
ing base classes defined by the framework must be sub- 
classed by the business application component 
developer: 



AccountControlType: 

[0038] The AccountControlType base class allows the 
framework to use any domain-specific class in the 

s generic data conversion engine. The application com- 
ponent developer must define a subclass of this class 
for each domain-specific class to be used by the engine. 
An instance of each of the component-defined sub- 
classes is then given to the generic data conversion 

10 engine. The engine maintains the order of this set and 
uses it during the generic mapping process. 

DomainGenericlrrlegrationKey: 

is [0039] The application component developer creates 
a single subclass of the DomainGeneridntegrationKey 
base class. This subclass converts the generic Integra- 
tion Key interface into one which conforms to domain- 
specific terminology, e.g., setProduct, setWarehouse. 

20 Each domain-specific interface on the subclass is cou- 
pled to one or more domain-specific AccountCon- 
trolType subclasses. 

The AccountControlType subclass serves as an index 
when building the GenericKey used by the generic map- 
25 ping process. 

GenericGIJ)issectionCreateTemplate: 

[0040] Subclasses of the GenericGLDissectionCrea- 
30 teTemplate class are used to encapsulate all the infor- 
mation needed by the financial integration framework to 
create 

a GenericDissection. Each template subclass is associ- 
ated with a DomainGenericDissectionType instance, 

55 which is used by the generic data conversion engine to 
select the proper mapping subset when processing the 
template. Each template subclass allows the application 
component developer to pass all the necessary domain- 
specific information that is required for the dissection 

40 when an instance of the subclass is instantiated. The 
subclass then packages this information into a form 
which is compatHe with the generic data conversion 
engine. Part of this processing includes building an Inte- 
ntion Key using the cfomain-spedfic subclass 

45 described earlier. 

[0041] The business application component must also 
create one or more instances of the DomainGenericOis- 
sectionType class, associating each instance with one 
or more AccountControlType subclasses. This assoda- 

50 tion defines the domain-specific dasses that are of 
interest of 

a particular dissection type. One instance of the 
DomairK3enericDissectionType dass is created for 
each GenericGU)issectionCreateTemplate subdass 
55 defined by the business application component. 

[0042] The finandal integration framework further 
includes a set of base classes which support the inter- 
faces used by the generic data conversion engine This 
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allows the financial integration framework to operate in 
the absence of 

a General Ledger application component. The base 
classes provided by the framework include: 

5 

GenericGUoumal 



replacement classes provided by the General Ledger 
component Other components using the financial inte- 
gration framework - and indeed, the framework itself - 
are not aware of this class replacement as all the func- 
tion needed to complete their portion of the financial 
integration task is defined at the generic base class 
level. 



[0043] This class represents a set of dissections [0049] Legacy non-object-oriented General Ledger 

which are to be posted concurrently to the General applications can be easily integrated into this framework 

Ledger (GL). Typically for a journal to be posted sue- 10 in the same way. The subclasses used for such integra- 

cessfully. the sum of its debit dissections must equal the tion are defined to map between the generic object-ori- 

sum of its credit dissections. ented framework interfaces and the procedural 

interfaces provided by the legacy application. 

GenericDissection [0050] The generic data conversion engine defined by 

is this invention provides, at its core, a generic mapping 

[0044] This class represents a specific financial entry process which is capable of mapping between 

(either debit or credit) which is to be posted to the Gen- instances of domain-specific classes defined by the 

era) ledger as part of a journal. It contains using components of the framework and instances of 

a GenericPostingCombi nation along with quantity and the General Ledger specific base classes defined by the 

value information. 20 framework. This mapping mechanism provides sepa- 

rate instances for each using component, so that each 

GenericPostingCombination component has the freedom to independently define its 

mapping rules without danger of interference from the 

[0045] This class identifies the General Ledger other components of the application, allows any number 

account that 25 of Dissection types to be defined genetically by the 

a dissection is to be posted to. It is composed of one or using component each of which can be associated with 

more GenericAnalysisCodes. any number of domain-specific classes to be used by 

the mapping engine, and allows the application user to 

Generic AnalysisGroup selectively enable the use of any or all of the domain- 

30 specific classes defined by the using component by 

[0046] This class represents a group of similar busi- coupling those classes to Generic Analysis Group class 

ness entities, e.g., department job function, cost center, instances previously defined by the user and associat- 

which are of interest to the user of a General ledger ing specific combinations of domain-specific class 

application. Each instance of a group is represented by instances to Generic Analysis Code class instances 

a GenericAnalysisCode. 35 defined by the user for each Generic Analysis Group. 

[0051] The engine also provides a generic journal 

GenericAnalysisCode building process which bundles the generic transactions 

supplied by the application component into a consofi- 

[0047] This class represents a specific business entity dated form compatible with the General Ledger appiica- 

wrthin a GenericAnalysisGroup. Instances of this class 40 tion component associated with the financial integration 

are defined by the user. During setup of the finanacia) framework 

integration framework, the user associates a GenericA- [0052] The generic mapping process must be capable 
nalysisCode instance with a set of domain-specific of working with domairvspeeffic classes without explicit 
object instances. These domain-specific object knowledge of their type or contents. Such knowledge 
instances are selected from the AccountControTTypes 45 must be avoided because otherwise the framework 
specified by the user as meaningful for the combination would be unacceptably coupled to a specific domain 
of DomainGen«icDissectionType and GenericAnaly- implementation and extension of the framework to new 
sisQroup. These mapping pairs form the core of the domain areas would become cumbersome, 
information which is used by the financial integration [0053] This is a primary problem of the framework, 
framework to process financial transactions. so which this invention provides a solution for. An Access- 
[0048] While the financial integration framework oper- Key/Keyables mechanism defined by frameworks of the 
ates in the absence of a Genera) Ledger application present invention allows the financial integration frame- 
component, such a component must be provided by the work to work with any domain-specific class generically 
application in order for any meaningful financial (For AccessKey see related patent application "Access 
processing to be completed. A General Ledger oompo- ss Key Objects'*, filed with the European Patent Office, 
nent is easily integrated into the framework by simply Application No. 97100566.6, filing date January 16, 
conf iguring the framework's object tactory to replace the 1997). Each domain-specific class of interest to an 
generic versions of the classes listed above with application component is assigned an ID, held generi- 
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cally as a subclass of the framework class AccountCon- 
trolType, known to the financial integration framework 
and a position within the Generic Key used by the map- 
ping engine. When a domain-defined Dissection is proc- 
essed by the framework, each domain-specific class 5 
instance is wrapped by a Generic Keyable and placed 
into the previously specified position within the Generic 
Key. This key can then be used during the mapping 
process for the Dissection. Once contained in this man- 
ner, the domain-specific mapping data can be manipu- 70 
lated genetically during the search for the user- 
specified set of Analysts Codes that will make up the 
Posting Combination for this Dissection. 
[0054] Each dissection type defined by a using appli- 
cation component specifies the set of domain-specific 75 
Attributes via a list of AccourrtCorrtroTType subclass 
instances which can be used by the generic mapping 
process. During application configuration, the user of 
the application must indicate which of the available 
Attnbute types will be used in the mapping process and 20 
the specific mappings which are valid for this installa- 
tion. 

[0055] As shewn in Figure 3, mappings may be 
defined for a dissection type 312 and AnalystsGroup 
311. i.e. a specialized mapping 301, or solely for an 25 
AnalystsGroup 311, i.e. a default mapping 302 which 
applies to all cfissection types in the absence of a suc- 
cessful comparison to a dissection type/AnalystsGroup- 
specific mapping. Each of the specific mappings speci- 
fied by the user are encapsulated into AccessKeys, just 30 
as the input from the domain-specific dissections will be 
during normal operation of the application. Thus, once 
the framework is configured in this way, the conversion 
process is automatic and can be carried out genetically 
within the framework by comparing GenericKey 35 
instances. 

[0056] As shown in Figure 4, the generic mapping 
process is part of the generic journal building process 
supported by the conversion engine. Neither the map- 
ping nor the conversion process is completed at the 40 
time the domain-specific application component creates 
a dissection template instance 401. Instead, these 
instances are collected and held by the financial inte- 
gration framework until the application initiates the 
generic journal building process 402. The first step of 45 
this process involves selecting a subset of dissection 
templates based on a configurable policy, for example 
based on a specific JournalCreationld provided by the 
application component when it created the dissection 
template. Each template in the set is then processed, so 
first by completing the generic mapping which results in 
the creation of 

a GenericPostingCombination, followed by building 
a GenericDissection from the GenericPostingCombina- 
tion and the remaining information held by the template. 55 
Once the GenericDissection is built, it can be inserted 
into the GenericJourna) 403 created for this subset of 
dissection templates. After all the dissection templates 



have been processed in this way, the GenericJournal is 
posted and financial integration processing is complete. 
[0057] Figure 5 shows an example of mapping for one 
Analysis Group for a particular Generic Dissection Type. 
In this case the Generic Dissection Type is STOCK 
VALUE 501, which is used to indicate to the financial 
portion of the application a change in the value of the 
stock on hand. The target financial application repre- 
sents its accounts in pieces. Each piece is called an 
Analysis Group and represents some aspect of interest 
to the user. A typical Analysis Group would be Depart- 
ment 502. Within an Analysis Group the specific values 
are called Analysis Codes 503. For example the Analy- 
sis Group Department might contain Analysis Codes 
like SALES. ENGINEERING, etc. Thus, an account is 
made up of a set of Analysis Codes each for an Analysis 
Group. 

[0058] In this particular example only Analysis Group 
2 - Department 502 is shown. For Analysis Group 2 only 
the Account Control type for Warehouse 506 is used. 
Figure 5 shows that warehouse "BB001" 507 maps to 
Analysis Code "BB" 504. Thus, when using the Stock 
type Generic Dissection type, given "BB001" for the 
warehouse Account Control type will result in the "BB" 
Analysis Code being used for Analysis Group 2. 
[0059] Figure 6 shows a more complex example with 
two Generic Dissection types (Stock Adjustment 607 
and Stock Value 608), three Analysis Groups (1 = Main 
Account 609, 2 = Department 610, and 3 = Product 
611), and three Account Control types (Product 612, 
Warehouse 613, and Cost Type 614). Map 601 shows a 
special case where a particular Analysis Code should 
be used for the Analysis Group no matter what Account 
Control type is used. In this particular case, Analysis 
Code "4550" will always be used. Maps 602, 603, and 
605 are similar to Figure 5 described above. Map 606 is 
used to shew that all possible Analysis Groups do not 
have to be used and in 606 no Analysis Code is desira- 
ble for Analysts Group 3 (not used) for this particular 
Generic Dissection type. Map 604 shows a case where 
more than one Account Control type is used. In this par- 
ticular case Cost Type 614 and Product 612 are used. 
Thus for a cost type of "CNS01 "(normal) 615 and a 
product of -BFTROr(trike) 616 the Analysis Code 
-1512- 617 would be used. 

[0060] Figure 7 shows an example of using the maps 
defined in Figure 6. In this example the specified 
Account Control type values are used for each of the 
Generic Dissection types to determine the appropriate 
Analysis Codes to build the Account for giving the infor- 
mation to the financial application. 

Claims 

1. A framework to be used for developing a software 
system, ag. for a business application, 
said framework is a financial integration framework, 
characterised in that said financial integration 
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framework comprises 

using non-financial component integration 
base classes, 

target financial component integration base s 
classes, and 

a generic data conversion engine. 



2. The framework according to claim 1 . wherein 
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a set of concrete classes are defined by said 
business application, said concrete classes are 
subclassed from said using non^inancial com- 
ponent integration base classes provided by 
said framework. is 

3. The framework according to claim 2, wherein 

function of said concrete classes is primarily 
derived from said base classes. 20 

4. The framework according to one of claims 1 to 3, 
wherein 

said target financial component integration 25 
base classes support interfaces used by said 
generic data conversion engine. 

5. The framework according to one of claims 1 to 4, 
wherein 30 

said generic data conversion engine provides a 
generic mapping process which is capable of 
mapping between instances of domain-specific 
classes defined by said using components and 35 
instances of said financial specific base 



The framework according to one of claims 1 to 5, 
wherein 40 

said target financial component integration 
base class support interlaces are used in con- 
junction with said generic data conversion 
engine to generate entries into said target 45 
financial component. 

A method of developing a software system using an 

Object Oriented Technology and a framework, 

said framework is according to one of claims 1 to 6. so 

A data storage medium characterised in that said 
data storage medium is storing a framework, 
said framework is according to one of claims 1 to 6. 

55 
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Fig. 1 
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101 
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NETWORK 113 
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NT 
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INPUT ACCOUNT CONTROL TYPE VALUES 
COST TYPE PRODUCT WAREHOUSE 



NORMAL 
CNS01 



MOUNTAIN BIKE 
BFMB01 



ROCHESTER 
RCH001 



RESULTING ANALYSIS COOES 
STOCK ADJ. DISSECTION: 

AG 1 = 4550. AG2 = RCH, AG3 = 100 
STOCK VALUE DISSECTION: 

AG1 = 1510, AG2 = RCH 



Fig. 7 
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SET OF CLASSES USED BY 
PARTICULAR SOURCE OF FINANCIAL 
TRANSACTIONS 201 



-SPECIALIZED 
AccountControIType 
DomainGenericlntegrationKey 
GenericGLDissectionCreateTemplate 

-AS IS 

DomainGenericDissectionType 



INTERFACE TO GENERAL 
LEDGER (GL) 203 



GenericGLJournal 
Generic Dissection 
GenericAnalysisGroup 
GenericAnalysisCode 




GENERIC MAPPING FACILITY 202 



GENERIC DATA CONVERSION ENGINE 



Fig. 2 
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Analysis Group Dissection Type 
311 312 



.. 301 

Integration Key Analysis Code 



Analysis Group 
311 



302 



Integration Key Analysis Code 



Fig. 3 



APPLICATION CREATES 
TEMPLATES FOR DISSECTIONS 

(DISSECTION TEMPLATES) 
AND ADDS THEM TO A QUEUE 



r 



401 



DISSECTION TEMPLATES ARE 
CONVERTED INTO DISSECTIONS 
AND COLLECTED INTO JOURNALS 



IT 



402 



GENERAL LEDGER JOURNALS EXIST \T 

A) VALIDATE 1 

B) POST TO GENERAL LEDGER 



403 



Fig. 4 
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GENERIC DISSECTION TYPE: STOCK VALUE 501 (WHS_STOCK_VALUE) 



ANALYSIS GROUP 2 - DEPARTMENT 502 
ACCOUNT CONTROL TYPE(S) 



WAREHOUSE 506 

BB001 (BOEBLINGEN) 507 
RC001 (ROCHESTER) 



ANALYSIS 503 
CODE DESCRIPTION 
BB 504 BOEBUNGEN 
RC ROCHESTER 



Fig. 5 



GENERIC DISSECTION TYPE 
STOCK ADJUSTMENT N 

601 



ANALYSIS GROUP 1 - MAIN ACCOUNT 



ACT 



FIXED ACC. USED 4550 STOCK ADJ. 



607 



609 



GENERIC DISSECTION TYPE 

STOCK VALUE . 

\— 608 

604 



AC DESCRIPTION 



614 



615 



616 



602 610 

ANALYSIS GROUP 2 - DEPARTMENT 



ACT (WAREHOUSE) AC 

\- 613 
BB001 (BOEBL) BB 

RC001 (ROCH.) RCH 



DESCRIPTION 

BOEBUNGEN 
ROCHESTER 



603 /~ 
ANALYSIS GROUP 3 - PRODUCT 



611 



ACT (PRODUCT) 
\_ 612 
BFMB01 : 
BFRB01 
BFTR01 



AC DESCRIPTION 

100 MOUNTAIN BIKE 

200 RACING BIKE 

300 TRIKE 



609 



ANALYSIS GROUP 1 - MAIN ACCOUNT 

ACT AC DESCRIPTION 

(COST TYPE; PRODUCT) 
_ / \_ 612 

CNS01 (NORMAL STK VALUE 
/ BFMB01 1510 MOUNTAIN BIKE 

BFRB01 1 51 1 RACING BIKE 
/BFTR01 1512 <TRIKE 617 
CDS01 (DAMAGED) 
BFMB01 1550 DAMAGED 
BFRB01 1550 DAMAGED 
BFTR01 1550 DAMAGED 

6C6 /- 610 

ANALYSIS GROUP 2 - DEPARTMENT 

ACT (WHS) AC DESCRIPTION 
\— 613 

BB001 (BOEBL.) BB BOEBLINGEN 
RC001 (ROCH.) RCH ROCHESTER 

^-606 
ANALYSIS GROUP 3 - NOT USED 



Fig. 6 
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